Bridling Concurrency to Boost Performance in Distributed STMs

Over the last years, a wide body of literature has been developed in the area of Software Transactional Memory (STM) systems and, recently, the first STM-based applications have started to be deployed in production systems [1]. One of the key lessons learnt from the development and deployment of these applications is that existing STM platforms suffer from a significant limitation: the lack of efficient replication schemes capable of fulfilling the scalability and reliability levels of real-world applications [1]. Replication of STM systems represents a very recent research field, and, at current date, only a few solutions have been proposed and evaluated [2]. On the other hand, since STMs and databases share the common notion of atomic transaction, the extensive research developed in the area of replicated databases represents a natural source of inspiration for the design of replication schemes for STMs. Among the plethora of database replication schemes, recent approaches are based on Atomic Broadcast (AB) [3] and a distributed certification procedure [4]. These schemes ensure the consistency of replicas only at commit-time via a distributed certification phase that uses a single AB to enforce agreement on a common transaction serialization order. This avoids distributed deadlocks, and provides nonblocking guarantees in the presence of (a minority of) replica failures. Unfortunately, the overhead of previously published AB based certification schemes can be particularly detrimental in STM environments [5]. Further, distributed certification schemes are based on an inherently optimistic approach: transactions are only validated at commit time and no bound is provided on the number of times that a transaction will have to be reexecuted due to the occurrence of a remote conflict. This can lead to undesirably high abort rates in high conflict scenarios. Also, when considering heterogeneous workloads containing mixes of short and long-running transactions (as it is actually the case for several well-known TM benchmarks [6]), the latter ones may be constantly aborted due to the occurrence of (remote) conflicts with a stream of shortlived transactions.